-
Notifications
You must be signed in to change notification settings - Fork 218
improve: dependent resource can be re-initialized #2026
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The workaround being proposed for Keycloak https://github.com/keycloak/keycloak/pull/22591/files#diff-2630e65f8b32c7c9b6249637101ba1d0221727b8c6e0ec482d7f29c76d4e9e45R195 |
@@ -365,7 +365,7 @@ public void setConfigurationService(ConfigurationService configurationService) { | |||
super.setConfigurationService(configurationService); | |||
|
|||
cache.addIndexers(indexerBuffer); | |||
indexerBuffer = null; | |||
indexerBuffer = new HashMap<>(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that initializing the buffer to a zero size is a good idea since it will immediately need to get resized the first time something is added to it. Can't we initialize it to some default, reasonable size if we want to avoid overprovisioning for nothing? I'm not sure what's the typical use pattern here, like how many indexers might we expect to have?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We mostly shouldn't worry about initializing to specific sizes. The value is used lazily - so using zero or one is effectively the same. If not specified it will default to 16, but you're only holding that memory ephemerally based upon the usage pattern here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess 0 leads to the internal table being initialized to size 1… which is reasonable if we expect a low number of indexer. No idea on the usage pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually there is index just for one case (at least this is what we see now) when there is many-to-one / many-to-many relationship between resource, see: https://javaoperatorsdk.io/docs/features#managing-relation-between-primary-and-secondary-resources. But yeah, maybe not necessary to optimizations like this, can be even confusing to read. will remove this number if not objections and have the default (as when initialized).
see linked issue